AWS Control Towerのラボをやりながら学んでみた-B1セットアップ編

こんにちは、臼田です。

みなさん、AWSをセキュアに利用できてますか？(挨拶

今回は少し前にGAとなったマルチアカウントで統制を利かせて管理するAWS Control Towerについて実際に触りながら学んでいきたいと思います。

「Control Towerって何？」「マルチアカウントでのAWS環境の管理手法に興味がある」「実際にやってみたい」という方に参考になるように書いていきます。

このブログではAWSから提供されているAWS Management Tools Lab ContentというコンテンツのLabsをベースに進めます。

上記ラボは廃止され、現在はAWS CONTROL TOWER IMMERSION / ACTIVATION DAYに変わっています。手順も変わっているのでラボの内容をご参照ください。このブログは雰囲気を味わう用途でご利用ください。

ラボにはBase LabsとAdd-on Labsがあり、Baseは下記の4種類あります。

• Lab B1 - High-level overview
• Lab B2 - Using Account Factory
• Lab B3 - Tasks in Control Tower
• Lab B4 - Deploy additional services on Control Tower

今回は初回ということでB1のラボによるセットアップと、あとはControl Towerの概要も(知っている知識ベースで)説明しようと思います。

AWS Control Towerとは

Control Towerはre:Invent 2018にてPreviewで発表されたマルチアカウントでのAWS環境の管理を簡単にできるようにするサービスです。2019年6月にGAになりました。

[新サービス] AWS Control Tower (Preview) が発表されました！ #reinvent

AWS環境の利用が活発になってくると、多数のAWSアカウントが乱立し統制を利かせることが難しくなってきます。

例えば各セキュリティ機能の有効化。CloudTrailやAWS Configが有効になっているか。例えば権限の管理。MFAが有効になっているか。例えばログの集約。不審なアクティビティがないかチェックするためにログを適切な場所に出しているか。

AWSではこれまでマルチアカウントで統制を利かせるために様々なサービスを提供してきました。マルチアカウントを集約するAWS Organizations。Organizationsの中で複数アカウントにまたがって統制を利かせるSCP(Service Control Policy)。コンプライアンスの準拠状況を確認するAWS Config Rulesとそれをマルチアカウントで集約するアグリゲータ。ログインを集約するAWS SSO(Single Sing-On)。

他にも様々な要素がありますが、これらを組み合わせて適切なマルチアカウント管理を行うためのベストプラクティスとしてAWS Landing Zoneというアプローチがリリースされました。上述のようにマルチアカウントで統制を利かせるために使わなければいけないサービスが多数あり大変なので、概念や利用方法をまとめてCloudFormationテンプレートとして提供されました。

ただ、テンプレートで提供されるだけだと結局その管理も大変になったり、常に各サービスをチェックして統制が利いているか確認する必要があり運用が煩雑になることもあり、1つのコンソールでまとめて管理できる形にサービス化されたものがControl Towerです(半分推測)。

だいたいこんな感じなので、Control Towerを理解するには下記のような点で難しいです。

• そもそも出てくるサービスすべてを理解していない(OrganizationsとかSCPとか)
• (なぜか)全容の構成図がない
• Landing Zone(ベストプラクティス)を理解していない
• (作ったあとの話ですが)自動的にいろいろ生成・設定されてどうなっているかよくわからない

というわけで私自身もすべてを理解しているわけではありません。なのでラボを触りながら学習していきます。

ちなみに、「(なぜか)全容の構成図がない」のでそれは今回作成しました。間違っているかもですがご容赦ください。

はい、把握するのが大変ですねｗ

各要素の説明はおいおいしていきます。(なぜか)Landing Zoneとも随所違うので作成するのにだいぶ苦戦しましたｗ

必要なもの

やってみる前にこの実習をしていく中で必要なものを説明します。

• 1つのマスターアカウント用のAWSアカウント
  • AWS Organizationsに未所属(あるいは削除済み)
  • 他にも制約があるかもなので新しいアカウントがオススメ(いろんな機能を利用するので)
• 2つの共有アカウント用のAWSアカウントのためのメールアドレス
  • アカウントは新規作成されます
  • 管理系機能
• 最低1つのユーザアカウント用のAWSアカウントのためのメールアドレス
  • アカウントは新規作成されます
  • 実際に利用する側のアカウント
• ちょっとしたコスト
  • 様々なセキュリティ機能やログ集約が使われるのと、作成されるネットワーク等がマルチAZでかっちりしているので(主にNAT Gatewayで)時間とともにコストを持っていかれます

マルチアカウントのサービスのため結構一人の権限ではできないことが多いです。ただ、読むだけでもいろいろ理解できると思うので一緒に手を動かせない方も一読する価値はあると思います。

ラボやってみた

それではLab B1 – AWS Control Tower Deployment and Beyondをやっていきます。

概要

このラボではControl Towerのセットアップと、セットアップした環境のいくつかを確認します。セットアップには60-90分程度かかると言われています。実際に触ってみたいと考えているタイミングがあれば、まずは上述の必要なものを揃えてセットアップまでは行っておくことを推奨します。

セットアップされるものは下記の通り。

• 新規のAWS Organizations
  • 共有アカウント用とユーザーアカウント用の2つの組織(AWS OrganizationsのOU)
• マスターアカウント配下に2つの追加アカウント
  • ログアーカイブ用とセキュリティ監査用
• 各種ガードレール
  • ポリシーを適用するための17個の予防ガードレール
  • 違反を検出するための8個の検出ガードレール
• AWS SSOとそのために利用するディレクトリ及びグループ

Control Towerのセットアップ

それではマネジメントコンソールからセットアップしていきます。まずはサービスからControl Towerへアクセスします。なお、2019/09/29時点では東京リージョンでは提供されておらず、対応しているリージョンはバージニア、オハイオ、オレゴン、アイルランドの4つです。

開いたら「ランディングゾーンの設定」を押します。

ちなみに先述の通りOrganizationsが削除されていないと下記のようにエラーが出ます。新規アカウントを用意するか、Organizationsの削除を行いましょう。(勝手に削除すると管理者に怒られることがありますので絶対にやめましょう)

気を取り直してセットアップです。最初に共有アカウント用のメールアドレスを入力していきます。ログアーカイブ用とセキュリティ監査用です。ログアーカイブは主に保全用で全AWSアカウントからCloudTrailやAWS Configなどのログが集約されてS3に保存されます。セキュリティ監査用は全AWSアカウントからGuardDutyやAWS Config Rulesなどの各種セキュリティアラートが飛んできたり、(おそらくインシデント対応等のための)各AWSアカウントへの特権を有しています。ここで入力したメールアドレスが各アカウントのルートアカウントのメールアドレスとなります。

続いて利用規約に同意するチェックを入れて「ランディングゾーンの設定」を押します。

するとセットアップが開始されます。あら簡単！！

推定残り時間60分と表示されます。

ちなみにラボには下記のような記載があります。

Note: It is normal to see the progress staying at 99% for 15-20 minutes

意訳: 15〜20分間、進行状況が99％のままになるのは正常です

真顔での注意事項なのかウィットに富んだジョークなのかはわかりませんｗ

今回は約50分でセットアップが完了しました。管理されているアカウントとガードレールの適用状況が表示されます。なお、裏でOrganizationsへの所属やSSOのための確認メールが飛んでいるので承認してください。

セットアップされた環境の確認

このセットアップで下記図(再掲)のうち、右下のユーザアカウント以外が作成されました。

ダッシュボードではLanding Zoneの課題であった各種コンプライアンスの状況が確認できるようになっています。下の方にスクロールすると、非準拠リソースや組織・アカウント別でのコンプライアンス準拠状況の一覧がありました。

更に下には適用されているガードレールが表示されました。

現時点で存在するガードレールを一覧にしてみました。最初から有効になっているものはガイダンス: 必須になっているものです。ログアーカイブへのログの設定やTrail・Configの設定などセットアップされたものが変更できないようにする用途が必須となっていて、セキュリティ強化のための設定は強く推奨や選択的になっています。

名前	ガイダンス	カテゴリ	動作
ログアーカイブの保存時に暗号化を有効にする	必須	監査ログ	予防
ログアーカイブのアクセスログ作成を有効にする	必須	監査ログ	予防
ログアーカイブへのポリシーの変更を不許可にします	必須	モニタリング	予防
ログアーカイブへのパブリック読み取りアクセスを不許可にする	必須	監査ログ	検出
ログアーカイブへのパブリック書き込みアクセスを不許可にする	必須	監査ログ	検出
ログアーカイブの保持ポリシーを設定する	必須	監査ログ	予防
CloudTrail への設定変更を不許可にします	必須	監査ログ	予防
CloudTrail イベントと CloudWatch logs を統合する	必須	モニタリング	予防
利用可能なすべてのリージョンで CloudTrail を有効にする	必須	監査ログ	予防
CloudTrail ログファイルの整合性検証を有効にする	必須	監査ログ	予防
AWS Control Tower によって設定された CloudWatch への変更を不許可にします	必須	Control Tower のセットアップ	予防
AWS Control Tower によって設定された AWS Config アグリゲーションへの変更を不許可にします	必須	Control Tower のセットアップ	予防
AWS Config への設定変更を不許可にします	必須	監査ログ	予防
利用可能なすべてのリージョンで AWS Config を有効にする	必須	監査ログ	予防
AWS Control Tower によって設定された AWS Config ルールへの変更を不許可にします	必須	Control Tower のセットアップ	予防
AWS Control Tower によって設定された IAM ロールへの変更を不許可にします	必須	Control Tower のセットアップ	予防
AWS Control Tower によって設定された Lambda 関数への変更を不許可にします	必須	Control Tower のセットアップ	予防
Amazon SNS によって設定された AWS Control Tower への変更を不許可にします	必須	Control Tower のセットアップ	予防
AWS Control Tower によって設定された Amazon SNS のサブスクリプションへの変更を不許可にします	必須	Control Tower のセットアップ	予防
MFA なしで IAM ユーザーへのアクセスを許可しない	選択的	IAM	検出
MFA なしで IAM ユーザーへのコンソールアクセスを許可しない	選択的	IAM	検出
S3 バケットのクロスリージョンレプリケーションを許可しない	選択的	データセキュリティ	予防
MFA なしで S3 バケットでの削除アクションを許可しない	選択的	データセキュリティ	予防
バージョンが有効かされていない S3 バケットを許可しない	選択的	データセキュリティ	検出
EBS 用に最適化されていない EC2 インスタンスタイプの起動を許可しない	強く推奨	オペレーション	検出
EC2 インスタンスにアタッチされていない EBS ボリュームを許可しない	強く推奨	オペレーション	検出
EC2 インスタンスにアタッチされた EBS ボリュームの暗号化を有効にする	強く推奨	データセキュリティ	検出
RDS データベースインスタンスへのパブリックアクセスを許可しない	強く推奨	データセキュリティ	検出
RDS データベーススナップショットへのパブリックアクセスを許可しない	強く推奨	データセキュリティ	検出
暗号化されたストレージではない RDS データベースインスタンスを許可しない	強く推奨	データセキュリティ	検出
RDP を介したインターネット接続を許可しない	強く推奨	ネットワーク	検出
SSH を介したインターネット接続を許可しない	強く推奨	ネットワーク	検出
ルートユーザーとしてのアクションを許可しない	強く推奨	IAM	予防
ルートユーザーのアクセスキーの作成を許可しない	強く推奨	IAM	予防
ルートユーザーに対して、MFA を有効化する	強く推奨	IAM	検出
S3 バケットへのパブリック読み取りアクセスを不許可にする	強く推奨	データセキュリティ	検出
S3 バケットへのパブリック書き込みアクセスを不許可にする	強く推奨	データセキュリティ	検出

SSOの確認

メールで届いたSSOの情報を元にSSOでパスワード登録してログインします。

SSOの画面が出てきます。各アカウントへここからSSOできるようになっています。今回はMasterアカウントを選んでAWSAdministratorAccessの権限でManagement consoleを選んでマネジメントコンソールにアクセスします。

CloudFormation StackSetsの確認

SSOの動作確認のついでに、セットアップで何が行われていたかの確認の一貫でCloudFormationのStackSetsを確認します。サービスからCloudFormationにアクセスし、スタックセットを選びます。一覧に各種実行内容が見れます。

一覧にすると下記のようになります。最初からログアーカイブへのログの集約設定や各種セキュリティ設定などが入っています。

StackSet名	説明
AWSControlTowerBP-BASELINE-CLOUDTRAIL	すべてのアカウントでAWS CloudTrailを構成する
AWSControlTowerBP-BASELINE-CLOUDWATCH	Cloudwatchルール、ローカルSNSトピックの構成、ローカルSNSトピックからセキュリティトピックへの通知の転送
AWSControlTowerBP-BASELINE-CONFIG	すべてのアカウント/リージョンでAWS Configを設定します
AWSControlTowerBP-BASELINE-ROLES	すべてのアカウントに必要なすべてのベースラインロールを作成します
AWSControlTowerBP-BASELINE-SERVICE-ROLES	CTが使用するサービス（AWS Config、SNSなど）のすべてのアカウントに必要なすべてのサービスロールを作成します
AWSControlTowerBP-SECURITY-TOPICS	SNSとAWS CloudWatchを使用した中央監視とアラート
AWSControlTowerGuardrailAWS-GR-AUDIT-BUCKET-PUBLIC-READ-PROHIBITED	コアアカウントでAWS Configルールを設定して、S3バケットがパブリックアクセスを許可しないことを確認します
AWSControlTowerGuardrailAWS-GR-AUDIT-BUCKET-PUBLIC-WRITE-PROHIBITED	コアアカウントでAWS Configルールを設定して、S3バケットがパブリックアクセスを許可しないことを確認します
AWSControlTowerGuardrailAWS-GR-S3-BUCKET-PUBLIC-READ-PROHIBITED	ガードレールを適用するためのStackSet
AWSControlTowerGuardrailAWS-GR-S3-BUCKET-PUBLIC-WRITE-PROHIBITED	ガードレールを適用するためのStackSet
AWSControlTowerLoggingResources	ログアーカイブアカウントに必要なリソースをセットアップするStackSet
AWSControlTowerSecurityResources	監査アカウントに必要なリソースをセットアップするStackSet
AWSControlTowerBP-VPC-ACCOUNT-FACTORY-V1	アカウントがプロビジョニングされると、このスタックが実行され、ベースラインに基づいてアカウント構成がセットアップされます

以上でB1のラボは終了です。

まとめ

Control Towerの概要説明とB1ラボのセットアップを行いました。Control Towerがどのようなものかや、少しだけ良さが伝わったかと思います。

各種セキュリティ設定やガードレールはセキュアにマルチアカウントを管理する上では非常に有用です。

次回B2ラボではアカウントファクトリという機能を利用して実際に利用するAWSアカウント(ユーザアカウント)を作成していきます。